导读：直播业务的核心功能有两个，一个是实时音视频推拉流，另一个是直播间消息流的收发。本文主要介绍百度直播服务内的消息服务系统的设计实践和演化。直播间内用户聊天互动，形式上是常见的IM消息流；但直播消息流不仅仅是用户聊天。除用户聊天外，直播间内常见的用户送礼物、进场、点赞、去购买、主播推荐商品、申请连麦等互动行为的实时提醒，也是通过消息流下发的。此外，直播间关闭、直播流切换等特殊场景，也依赖消息流的实时下发。消息流可以认为是直播间内主播与用户间实时互动和直播间实时控制的基础能力。如何构建直播的消息系统，又有哪些挑战需要解决，我们来梳理一下。直播间内聊天消息，经常被类比于群聊。群聊是大家比较熟悉的即时通讯场景，直播间内聊天和群聊，二者有相似性，但也有本质的区别。- 同时参与人数不同：群聊的参与人数上千人就是很大的群了；但对于高热度的大型直播场景，例如国庆、阅兵、春晚等，单直播间累计用户是百万甚至千万量级的集合，同时在线人数可达数百万人。
- 用户与群和直播间的关系不同：用户进群退群，是相对低频的操作，用户集合相对固定，用户进出的变更频度不会特别高；而用户进出直播间，是非常频繁的，高热度直播的单直播间每秒面临上万用户的进出变更。
- 持续时间不同：群聊建立后，聊天持续时间可能比较长，几天到数月都有；而直播间大部分持续不超过几个小时。
- 单直播间每秒上万用户的进出变更；实际进入直播间峰值不超过2万QPS，退出也不超过2万QPS。
支持在线百万、累积千万两个集合，每秒4万QPS更新，有一定压力，但有支持高读写性能的存储应该可以解决，例如redis。面对百万在线用户，上下行都有大量的消息，从直播用户端视角分析：- 实时性：如果消息服务端做简单消峰处理，峰值消息的堆积，会造成整体消息延时增大，且延时可能产生很大的累积效应，消息与直播视频流在时间线上产生很大的偏差，影响用户观看直播时互动的实时性。
- 端体验和性能：端展示各类用户聊天和系统消息，一般一屏不超过10-20条；如果每秒有超过20条的消息下发，端上展示的消息基本会持续刷屏；再考虑到有礼物消息的特效等；大量的消息，对端的处理和展示，带来持续高负荷。所以，对于一个长时间观看直播的用户端来说，如果出现持续的大量消息，端的消息消费会有显著的性能压力，且过多消息会有累积效应。
综合考虑直播业务场景，对于消息服务的需求目标如下：- 性能方面，消息服务能支持同一直播间内百万以上用户同时在线下发；
- 基于合理的端用户体验，单直播间内每秒消息数假设不超过N条。
现在，问题的核心是，如何做到把不超过N条的消息，在S秒内，下发到直播间内的百万用户，假设N<=20，S<=2。- 对于群group-1，分配一个群公共消息信箱group-mbox-1；
- 群group-1内的用户user-1，由手机端APP-1上发出消息msg-1；
- 服务端接收到消息msg-1，检查user-1是否有权限，如有权限，将msg-1存储到群信箱group-mbox-1，生成相应msgID-1；
- 服务端查询group-1对应的用户列表groupUserList-1；
- 基于groupUserList-1拆分出所有独立群用户：user-1、user-2。。。user-n；
- 对于每一个用户user-i来说，需要查询用户user-i的所在设备device-i-1、device-i-2、device-i-m（因为一个账号可能登录多个设备）；
- 对于每个设备device-i-j来说，长连接通道都会建立一个独立的长连接connect-j以服务于该设备；但由于connect-j是由端上APP-1连接到长连接服务的，具有动态性，所以，查询device-i-j与connect-j的对应关系时，需要依赖一个路由服务route来完成查询；
- 在查得connect-j后，可以通过connect-j下发msg-1的通知groupmsg-notify-1；
- 如果用户user-i正在使用device-i-j的手机端APP-1，用户user-i就可以立即从长连接connect-j上收到msg-1的通知groupmsg-notify-1；
- 在接收到groupmsg-notify-1后，手机端APP-1中的消息SDK根据端本地历史消息记录的最后一条消息latestMsg对应的消息ID即latestMsgID，来向服务端发起拉消息请求fetchMsg，拉取group-1中从latestMsgID+1到最新的所有消息；
- 服务端收到拉消息请求fetchMsg后，从group-mbox-1中取出latestMsgID+1到最新的所有消息，返回给端；如果消息过多，可能需要端分页拉取；
- 端APP-1拉取到group-1中从latestMsgID+1到最新的所有消息，可以做展示；在用户在会话中阅读后，需要设置所有新消息的已读状态或者会话已读状态。
如果完全重用普通群聊消息的下发通知到端拉取的全过程，对于user-1发的一条消息msg-1，如果需要支持一个实时百万量级的群消息，大概有以下几个每秒百万量级的挑战：首先，秒级拆分出用户列表groupUserList-1，需要秒级读出百万的用户列表数据，对于存储和服务是第一个百万级挑战。第二，对于拆分出群中的所有独立用户user-i，需要秒级查询出百万量级的device-i-j，对于存储和服务是第二个百万级挑战。第三，对于所有device-i-j，通过动态路由服务route，需要秒级查询出百万量级的connect-j，对于存储和服务是第三个百万级挑战。第四，对于通过长连接connect-j下发时，需要支持秒级下发百万量级的群消息通知groupmsg-notify-1到对应的connect-j上，对于长连接服务是个百万级的挑战。第五，对于收到消息通知的所有端APP-1，需要支持百万QPS端从服务端拉取消息请求fetchMsg，对于消息信箱服务，这是也是一个百万量级的挑战；考虑到实际各端latestMsgID可能不同，可能的优化方式会更复杂一些，带来的性能影响会更大。第六，如果在绝大多数用户是在线聊天的场景，设置已读状态也会有百万量级QPS对服务端的压力。显然，完全重用群聊的消息流程，对消息服务和长连接服务带来的压力是巨大的。现在，我们来分析以上每个百万量级的挑战，是否有优化的空间。- 对于①拆分用户列表和②查询用户对应设备，如果存储上将二者合并集中起来，也就是优化直播间内用户列表的存储，扩展设备信息，可以减少一次user->device的百万QPS查询，可以优化。
- 对于④下行通知和⑤端拉取fetchMsg的可靠消息拉取模式，考虑到直播消息允许部分折损丢弃，可以只做单向消息下发，而不做拉取，对于大部分连接保持在线的用户，也是可以接受的。所以可以优化，只保留下行通知（包含消息体），而舍弃端拉取。
如上优化后，减少了②⑤⑥三个百万量级压力请求，但还有①拆分用户列表③动态路由查询④长连接下发，这三个百万量级步骤需要处理。对于①拆分用户列表，支持百万量级用户列表查询，比较常规的思路是支持基于群groupID的批量查询，例如一次可以查出100个用户，1万QPS查询就可以支持到百万；基于群groupID把用户数据的存储，分散到多个主从实例和分片上，控制好打散粒度不出现热点，基本能做到，只是存储资源可能消耗较多。 对于③动态路由查询，表面上看，面临的问题与①类似，但却有些不同。因为群的用户列表，是基于群groupID做key，建立一个表或多个打散的表；而device-i-j的查询是完全分散的，也是需要批量查询能力，但是完全分散的设备信息查询，不能只针对特定key做优化，需要动态路由服务支持整体上达到百万QPS的查询性能。对于④长连接服务下发，由于长连接服务不依赖外部的存储服务，如果整体要支持百万量级的下发能力，若长连接单实例能支持1万的下发能力，整体上100个实例就能支持到百万量级下发。基于以上分析，支持百万量级的消息下发，初见曙光。似乎只要优化好用户列表、动态路由的存储/查询和长连接的容量扩容，但所有的前提是需要消耗大量存储和机器资源。一方面，平时没有热点直播时，可能单场直播并发在线用户数峰值不超过1万人，甚至不到1000；在业务初期，整体直播在线用户峰值可能也不超过10万。这就意味着，为了支持百万量级的峰值，资源整体上有几十倍的冗余。另一方面，如果突然来了一场热度非常高的直播，可能需要支持的不只是100万量级消息下发，可能是500万以上的量级（例如国庆阅兵、春晚等）。这样的话，每次大型直播得提前预估可能的在线用户峰值，如果超过当前设计容量，需要对①用户列表③动态路由查询④长连接服务，分别扩容和压测；或者在可接受的情况下，做服务降级或拒绝服务。而实际上，在线用户峰值量级很难估计准确，这样会造成实际资源利用率很低，扩缩容的操作频繁，运维成本高。是否选择这个方案，也是很令人纠结。也有人提过拆分多个群组的方案，例如，如果一个群组最多支持1万用户，开100个群就可以支持一百万用户；再建立一个虚拟群，将这100个群关联起来，似乎可行。但如果仔细分析，会发现以上提到的几个问题①拆分用户列表③动态路由查询④长连接下发，高压力依然存在，还是不可避免。问题一：多群组消息不同步。如果两个用户在一起看直播，而所属群不同，看到的消息会完全不同。问题二：直播场景用户是动态进出的，也就是说群组成员非常不稳定，在线用户峰值波动也比较大。如果是根据在线人数增长，动态新开群组，可能第一个群用户已经很多了，第二个群刚开始用户比较少；或者，在峰值期间开了比较多的群，随着热度降低用户离开，用户变得分散，一些群的用户可能较稀少，聊天互动较少，这时需要缩容合并群。如何平衡多个群的用户，达到好的业务效果，也是比较难做的。支持实时高并发百万量级同时在线用户的直播消息架构，组播mcast方案的提出及演化。是否要采用以上基于群聊的优化方案，还是可以另辟蹊径？先暂时抛开群收发消息流程，对于消息下发来说，如果一定要说一个步骤是必不可少的，那一定是长连接下发这步了。没有通过长连接下发，消息就无法最终到达用户；当然有人说轮询拉取也可以替代长连接下发，来获取消息，但显然轮询拉取的性能压力和实时性与长连接下发相比差很多，故不在讨论范围。如果能简化为，给长连接服务下发消息时指定一个类似的groupID，长连接服务能直接拆分到所有群组用户相关的长连接connect-j，就可以省略掉用户列表拆分和动态路由查询的百万量级查询。这样的话，消息下发的压力将主要由长连接服务来承受，服务端也不需要对多个系统扩容，直播消息的优化可能会大为简化。根据这个思路，相当于在长连接服务中，对连接connect也建立群组的概念。基于连接组的设想，我们设计了一套长连接的组播mcast机制。- 每个长连接组播mcast有全局唯一的标识mcastID。
- 长连接组播mcast支持创建、删除、修改、查询等管理操作。
- 长连接组播mcast是若干长连接在线用户的连接connect的集合。
- 一个用户user-i在设备device-i-j上，对于特定应用APP-k来说，建立唯一的一个长连接connect-j-k；（此处暂时不区别登录用户和非登录用户）。
- 长连接组播mcast与组内长连接connect-j-k的关系维护，不需要额外的独立存储，是维护在每个长连接服务的实例上。
组播mcast-m的路由route-m，是一个长连接服务实例的集合LcsList，记录了所有加入mcast-m的长连接connect-i所在长连接服务实例lcs-j。- 消息sdk通过长连接，发出上行请求mcastJoin（mcast-m）。
- 业务层收到来自长连接实例lcs-i上的连接connect-i的mcastJoin请求，校验mcast-m的合法性。
- 业务层请求路由层建立基于组播mcast-m的组播路由mcastRoute-m，将长连接实例lcs-i加入组播路由mcastRoute-m中。
- 业务层请求长连接服务层，请求mcastJoin所在长连接实例lcs-i，将请求所在连接connect-i加入到mcastConnectList-m中。
离开组播mcast，与加入组播mcast基本类似，由客户端调用消息sdk离开mcast-m，发出上行请求mcastLeave（mcast-m），长连接服务端更新路由和mcastConnectList-m信息。基于组播mcast的长连接消息推送过程，是一个1:M * 1:N的扩散放大过程，具体过程描述如下：- 一条消息msg-1推送，目的地是ID为mcast-m组播；
- 后端业务模块根据目的mcast-m，做一致性hash选择出mcast路由分发模块实例mcastRouter- i，发送msg-1到mcastRouter-i；
- mcast分发路由模块实例mcastRouter-i，根据mcast-m的组播路由mcastRoute-m，查找所对应的接入实例路由记录列表mcastLcsList-m，拆分出mcast-m所有的长连接接入实例lcs-1..lcs-M，分别并发发送msg-1到长连接实例上；
- 一个长连接服务实例lcs-j，收到消息msg-1推送后，根据组播mcast-m查找组播连接列表mcastConnectList-m，查出mcast-m内所有的连接connect-m-1..connect-m-N，并发推送msg-1到消息客户端sdk-m-1..sdk-m-N；
- 消息客户端sdk-m-o收到msg-1后，递交给上层业务（例如直播sdk）。
- 组播mcast的路由维护，主要压力在于mcastJoin和mcastLeave，而Join的量级峰值请求很难超过2万qps；访问压力比百万低两个数量级。
- 组播mcast的消息推送流程，在一级路由mcastRoute拆分到长连接实例时，一般在几十到百量级，成本很低。
- 组播mcast在长连接单实例内的消息推送，是单进程内的多连接并发发送，经优化后线上实测，在单实例保持25W长连接的情况下，单实例压测可达8Wqps的mcast稳定下发，保守按5Wqps容量评估；多个长连接实例间，是完全的并发，可以较容易的水平扩容。
- 综上可知，对于100Wqps的下发，20个长连接实例就可以完全负荷(20*5W=100W)，且有一定裕量。如果500Wqps的下发，也不超过100实例；1000W的下发，如果以8W单实例较大的负荷承载，125实例就可以支持。
看上去，基于以上组播mcast机制，我们建立了一套高效的支持百万量级QPS的长连接下发机制，当前长连接服务的容量就可以支持，基本不用扩容。但是否能完全满足直播业务场景需求，还需要进一步讨论。对于每秒1条消息，扩散到100W用户，甚至500W用户，以上组播mcast机制似乎都能应对。但直播间内消息的实际情况是，热门的直播每秒用户上行聊天消息会有很多，除聊天消息外，直播间还有人数、进场、点赞、分享等定期和不定期发送的很多种类系统消息。如果假设每秒峰值有100条各类消息，100W*100=1亿，简单按单实例5Wqps算，需要2000个实例才能支持，虽然比老的群聊系统应该好很多，但系统还是遇到大量资源冗余或应对峰值需要大量扩容的老问题。是否能有更好的解决方式？2.4.7.1 延时聚合
这里我们考虑常见的一个优化思路，是通过批量聚合的模式来提高系统性能。如果将这100条消息，每秒聚合打包一次来统一下发，QPS还是100W，长连接系统的下发QPS不变，但每秒下发消息量级可以达到1亿，这个聚合方案实测是可行的。聚合模式，我们付出的成本是消息时延的上升，1秒的聚合平均时延增加500ms，用户体验损失不算大，但系统下发消息量级可以提升百倍，综合评估成本收益来看是合理的。考虑到直播的实际场景，大多数场景下秒级的聚合和时延是可以接受的。聚合延时下发，长连接单实例QPS问题解决了，随之而来的是，长连接单实例下发的带宽压力问题。例如，长连接单实例需要下发10000长连接时，每秒100消息，消息平均2K字节，实际带宽为2K*100*10000*8=15625Mbps，这已经超过单物理机的万兆网卡的带宽容量。另一方面，从全局带宽来看，也高达1.5Tbps，带宽资源对于机房出口也会带来压力，这样的带宽成本过高，需要削减带宽使用或有更好的替代方案。面对下发数据量带宽消耗过大的问题，在不改动业务数据的前提下，我们采用了数据压缩的解决方案。而压缩是CPU密集型的操作，由于直播业务的实时性，不能简单考虑压缩比，在综合平衡压缩比、压缩时延和压缩CPU消耗后，调优压缩库后实测的平均压缩比达到6.7 : 1，数据量压缩到原来的15%左右，这样15625Mbps*15%=2344Mbps=2.29Gbps；单机万兆网卡的带宽容量，最多承载4.27万的长连接下发，虽然没有达到5万，基本也可以接受。从全局带宽来看，峰值也削减到不超过230Gbps，收益很明显。进一步考虑，直播场景下，不仅是有较高的峰值消息量级，而是在直播过程中有持续的高消息量级压力；这不仅对于服务端是压力，对于客户端来说也是个挑战。持续的高消息量级，一方面，客户端在接收、展示等方面有明显的压力；另一方面，直播界面上过多过快的消息刷新，对于用户体验也是有害无益的。所以，在综合平衡用户体验和客户端性能的基础上，消息服务端增加了结合消息优先级的分级频控限速机制，单用户客户端并不需要承受每秒100条的压力，削减每秒下发消息后，长连接单实例每秒下发5-8万长连接，CPU和带宽都是可以稳定支持的。我们提供了基于消息优先级的实时下发机制，对于高优消息可以立即触发聚合下发，不会增加聚合延时；而对于普通中低优消息，还是做延时聚合下发。组播mcast机制的出发点，在百万量级高并发在线的场景下，保障在线用户的消息到达，允许不在线用户接收消息的部分折损，付出合理的技术复杂度和成本，取得服务质量和性能平衡。而针对在线用户的消息到达，还有个关键问题是如何保障用户的长连接在线。为了提升长连接服务的接入稳定性和可达性，我们在以下几个方面做了优化。长连接服务在国内三大运营商的华北华东华南区域均部署了接入点入口；针对有部分国外用户的直播场景，增加了香港机房的独立接入点入口。针对部分用户的DNS劫持问题和解析错误问题，消息SDK接入了HTTPDNS服务并优化本地缓存，形成多级域名解析保障体系，提升了域名解析的可靠性，减少了DNS劫持和错误率。长连接的心跳是保活探活的重要手段，针对直播场景实时性高的特点，为了尽快发现长连接断链，在组播mcastJoin后，长连接心跳也调整为间隔更短、服务端动态可控的智能心跳。这样在及时发现连接异常后，消息SDK可以快速主动重新建连。
在直播间用户已加入组播mcast的情况下，如果长连接断链，长连接服务端会主动或被动的触发清除组播mcast成员。而长连接重建连恢复时，直播业务层也需要监听连接恢复信号，重新加入组播mcast，以恢复组播mcast的消息通路。综上所述，组播mcast机制，有效的解决了百万量级同时在线用户的消息实时下发问题；对于短时断链和消息过多，允许部分消息的丢弃；满足了直播场景消息的设计目标。- 消息服务和路由层压力较轻，整体压力只由长连接层承载，易于水平扩容。
- 基于延时聚合下发，辅以压缩限速，可以很好的解决下行QPS与带宽的性能问题。
- 系统整体下行的QPS和带宽是完全可控的。100W在线用户的下行最大QPS是100W，500W在线用户的下行最大QPS是500W。单实例的下发能力5-8万QPS是稳定的。因此，可以很容易判断整体的系统容量，特殊场景是否需要扩容。
- mcast机制虽然是针对直播场景提出的，但本身设计具有通用性，可以应用于其他需要实时在线大量用户分组的消息推送场景。
在组播mcast机制解决了百万量级的在线用户实时消息下发后，直播消息的场景不断扩大，不断有直播创新业务提出新的消息需求。相应的，组播mcast的服务机制也需要与时俱进，不断在深度和广度上拓展优化。以下重点介绍一下历史消息和礼物消息。对于刚进入直播间的用户来说，需要看到一些最近的聊天记录，以增强聊天互动氛围并帮助了解直播的进展；对历史聊天记录感兴趣额用户，还可以追溯更多的消息历史。这就产生了聊天历史的需求。为了支持这类历史消息的需求，解决方案是对于每个组播mcast申请开通一个组播公共消息信箱mcast-mbox服务。- 对于用户消息和其他有持久化需要的消息，全部写入这个消息信箱。
- 用户可以指定组播mcastID，按时间区间和要拉取得消息条数，来获取组播mcast的历史消息。
- 消息信箱内的一条消息msg，有唯一的消息标识符msgID。
- 一条消息msg，还包括有发送方信息、接收方信息、消息类型、消息内容等字段，此处可以暂时忽略。
- 一个消息信箱mbox，有唯一的信箱标识符mboxID。
- 一个消息信箱mbox是一个容器，存储有序的消息列表msgList；消息列表msgList按msgID排序的。
- 消息信箱服务，对指定信箱mbox支持单条消息或批量消息的写入。
- 消息信箱服务，对指定信箱mbox支持基于msgID的单条消息或批量消息的查找。
- 消息信箱服务，对指定信息mbox支持从msgID-begin到msgID-end的范围查找。
实际上，最常用的就是基于msgid范围的消息拉取；这里的消息信箱服务是时间线timeline模型，有兴趣的同学可以进一步参考时间线timeline模型的相关信息。- 用户送礼给主播，主播侧需要尽快、可靠地收到礼物消息通知，才能及时的给予用户反馈。
- 送出礼物的用户，本地就可及时展示礼物效果，无消息通知强诉求。
- 直播间内其他用户，需要收到礼物消息，以展示礼物效果，提升直播间互动氛围，激发其他用户送礼。
- 礼物消息涉及用户订单和购买行为，需要由服务端确认发出。
- 增加一个独立的可靠消息组播mcast通道（如图4中组播mcast-2），专供高优可靠消息的收发；与其他普通消息、系统消息在数据流层面隔离，减少相互干扰；
- 对于普通用户侧的端消息SDK，礼物消息组播mcast通道虽然是新增独立通道，消息收发逻辑与普通消息组播mcast通道保持一致；
- 对于主播侧，端消息SDK对于礼物消息组播mcast通道，需要支持推拉结合模式，以保障礼物消息的全部到达；即使有短暂的掉线，也需要取到全部礼物消息；
- 对于主播侧，在极端情况下，如果长连接建连有异常，消息SDK可以通过短连接接口轮询，来拉取礼物组播mcast信箱消息来兜底。
基于以上独立的可靠消息组播mcast通道方案，在未剔除一些异常场景的情况下，如主播下线未关播、数据偶发打点丢失等，礼物消息的触达率已达到99.9%以上。在百度直播的发展历程中，直播消息服务还面临着许多其他基础性问题和创新业务带来的其他挑战。现在这些问题都有了较好的解决方案，以下列举一些，供大家学习参考：- 如何支持多种客户端场景，安卓、iOS、H5、小程序、PC。
- 如何支持同一场直播的消息在百度APP和好看、全民、贴吧等矩阵APP的打通。
- 如何支持非登录用户。IM一般是支持登录用户，而直播场景也需要支持非登录用户。
- 长连接服务如果出了严重问题，是否有端获取消息的降级通道。
- 直播消息审核的机审人审如何做，如何支持先发后审和先审后发。
- 直播消息服务是如何支持创新业务的，如答题直播、直播带货、直播连麦等。
限于篇幅，以上问题在此不再做具体讨论，有兴趣同学欢迎直接联系探讨。自百度直播上线以来几年间，直播消息服务迎难而上，一路披荆斩棘为百度直播保驾护航，为百度直播提供了坚实的技术支撑和保障。未来，在支持直播创新业务、更细粒度的消息分级服务、直播消息基础服务的稳定性和性能等方面，直播消息服务会继续努力，夯实基础，持续创新，以支持直播业务更好更快的发展。
参考阅读
技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。